HANOI UNIVERSITY OF SCIENCE AND TECHNOLOGY
MASTER THESIS
Research and Application of Elliptic Curve Veriable
Random Function in Blockchain Consensus Protocol
BUI NGOC PHUONG
Phuong.BN212250M@sis.hust.edu.vn
Major : Computer Science
Thesis advisor : Assoc. Prof. Nguyen Binh Minh
Signature of advisor
Department : Department of Computer Science
Institute : School of Information and Communication Technology
Hanoi, 10-2023
ĐT.QT12.BM12 Lần ban hành: 02 Ngày ban hành: 28/04/2023
CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM
Độc lập – Tự do – Hạnh phúc
BẢN XÁC NHẬN CHỈNH SỬA LUẬN VĂN THẠC SĨ
Họ và tên tác giả luận văn : Bùi Ngọc Phương
Đề tài luận văn: Nghiên cứu áp dụng hàm ngẫu nhiên có thể kiểm chứng
trên miền đường cong elliptic trong giao thức đồng thuận blockchain
Ngành: Khoa học máy tính
Mã số SV: 20212250M
Tác giả, Người hướng dẫn khoa học và Hội đồng chấm luận văn xác nhận tác
giả đã sửa chữa, bổ sung luận văn theo biên bản họp Hội đồng ngày 28/10 với c
nội dung sau:
STT
Nội dung chỉnh sửa
Trang
1
Làm rõ đề xuất so với các nghiên cứu có liên quan
37-38
2
Làm rõ ưu/nhược điểm của đề xuất và hướng tiếp cận
38-39
3
Mô tả rõ giải pháp và đóng góp
2-3
4
Sửa đổi validator set từ block h thành block h-1 theo ý kiến
góp ý của hội đồng
30
5
Bỏ số chương của phần mở đầu Introduction và phần kết luận
Conclusion
1,50
6
Rà soát, hiệu chỉnh các lỗi soạn thảo
Ngày 7 tháng 11 năm 2023
Giáo viên hướng dẫn Tác giả luận văn
CHỦ TỊCH HỘI ĐỒNG
MASTER THESIS ASSIGNMENT
1. Student’s information :
Name : Bui Ngoc Phuong.
Phone : 033 323 5666 Email: Phuong.BN212250M@sis.hust.edu.vn
Class : KH/CLC2021B
Affiliation : Hanoi University of Science and Technology.
Duration : 11/02/2021 - 31/05/2021.
2. Thesis title : Research and Application of Elliptic Curve Verifiable Random Func-
tion in Blockchain Consensus Protocol
3. Declarations/Disclosures :
I - Bui Ngoc Phuong - hereby warrants that the work and presentation in this the-
sis were performed by myself under the supervision of Assoc. Prof. Nguyen Binh
Minh. All the results presented in this thesis are truthful and are not copied from
any other works. All references in this thesis including images, tables, figures and
quotes are clearly and full documented in the bibliography. I will take full respon-
sibility for even one copy that violates school regulations.
Hanoi, date month year 2023
Author
Bui Ngoc Phuong
Acknowledgments
I would like to dedicate these lines to deliver my most sincere gratitude to those who have
helped and shaped the person that I am today.
I would like to offer my gratitude to my parents for raising, shaping, loving and sup-
porting me with all of their hearts. Their unconditional love and hope are what gave me
the motivation to walk on this long and arduous road.
For my time in Hanoi University of Science and Technology, I would also like to
express my sincerest thanks to Associate Professor Nguyen Binh Minh, who not only a
glimmering figure for me to follow, but also guided me towards new ideas, solved difficult
questions I had, and all in all had helped me overcome major obstacles ever since I was
still a student. Joining BKC Labs might as well could be the most correct decision in my
university years. Your guidance and encouragement, your supervision and knowledge are
what permitted me to complete this master thesis.
I would also want to extend my gratitude to ToV Chain brothers, who stayed by my
side through all the storm that we faced, and to all of the lecturers at Hanoi University of
Science and Technology, who offered me the knowledge and techniques to advance in my
field.
For those who I loved, and those who loved me, thank you again for always being on
my side, cheering and motivating me. I could not have done this without you.
i
Thesis advisor : Assoc. Prof. Nguyen Binh Minh Bui Ngoc Phuong
ABSTRACT
Blockchain technology has been undergoing a major shift recently, with the adoption of
Proof-of-Stake consensus mechanism in lieu of Proof-of-Work due to the formers effi-
ciency and speed. One notable example of Proof-of-Stake is the Tendermint protocol,
which has been powering the entirety of Cosmos system - an ecosystem of multiple inter-
locked chains.
However, Tendermint’s choice of deterministically deciding the next block proposer
instead of utilizing a randomization function presents a huge window for malicious actors
to prepare and coordinate attacks on upcoming validator nodes, possibly crippling the at-
tacked chain, especially small chains with a few working nodes. Furthermore, randomized
number generation in this blockchain ecosystem still proves to be a challenge by reason
of blockchain’s inherent deterministic nature.
Aiming at the above problems, in this paper, we propose an improvement over Ten-
dermint consensus protocol, utilizing Elliptic Curve Verifiable Random Function, a fast
and secure pseudorandom generation algorithm suitable for deterministic systems like
blockchain. This novel approach will solve the problem of knowing the validator ahead of
time, whilst the verifiable random function module will be capable of supplying reliable
random numbers to the overlaying beacon chain - a blockchain capable of distributing
random numbers to users through smart contracts, and even other blockchains through
Cosmos’ InterBlockchain Communication Protocol.
The performed experiments with a prototype blockchain using the enhanced consensus
protocol demonstrated that the new consensus protocol improves Tendermint’s resilience
against network-layer attack vectors, while still maintaining adequate fairness and perfor-
mance.
Keywords: blockchain, consensus protocol, elliptic curve, verifiable random func-
tion, randomness, tendermint, chainlink, beacon chain
ii
Contents
Abstract ii
List of Figures iv
List of Tables vi
List of Acronyms viii
Introduction 1
1 Related Works 4
1.1 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Proof-of-Stake Consensus Protocol . . . . . . . . . . . . . . . . . . . . . 5
1.2.1 Proof-of-Stake . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Tendermint Consensus Protocol . . . . . . . . . . . . . . . . . . 7
1.3 Elliptic Curve Digital Signature . . . . . . . . . . . . . . . . . . . . . . 8
1.4 Elliptic Curve Verifiable Random Functions . . . . . . . . . . . . . . . . 12
1.4.1 Verifiable Random Functions . . . . . . . . . . . . . . . . . . . 12
1.4.2 ECVRF main functions . . . . . . . . . . . . . . . . . . . . . . . 13
1.4.3 ECVRF auxilliary functions . . . . . . . . . . . . . . . . . . . . 15
1.4.4 Security Properties . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4.5 Chainlink’s application of ECVRF . . . . . . . . . . . . . . . . . 17
2 Possible Attacks on Blockchain System 19
2.1 Attack Vectors on Blockchain . . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Peer-to-Peer network-based Attacks . . . . . . . . . . . . . . . . . . . . 20
2.2.1 Distributed Denial-of-Service . . . . . . . . . . . . . . . . . . . 20
2.2.2 Sybil Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.3 Eclipse Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.4 Routing Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
iii
2.3 Possible Attack Scenarios on Deterministic Proposer Selection Algorithm 22
2.3.1 Eclipse Attack Scenario on Deterministic Proposer Selection Al-
gorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.2 DDoS Attack Scenario on Deterministic Proposer Selection Al-
gorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4 Possible Attack Scenarios on Weak Randomization Algorithm . . . . . . 26
2.5 Precedents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.5.1 Network-layer Attack . . . . . . . . . . . . . . . . . . . . . . . . 27
2.5.2 Weak Randomization Attack . . . . . . . . . . . . . . . . . . . . 27
2.6 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3 Designing the Consensus Protocol 29
3.1 Proposal and PreVote Processes . . . . . . . . . . . . . . . . . . . . . . 29
3.2 Random Module and Beacon Chain . . . . . . . . . . . . . . . . . . . . 35
3.3 Proposed Method Compared To Related Works . . . . . . . . . . . . . . 37
3.3.1 Algorand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.2 Polkadot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.4 Method Advantages and Disadvantages . . . . . . . . . . . . . . . . . . 38
4 Implementation and Evaluation 40
4.1 Prototype Blockchain Creation . . . . . . . . . . . . . . . . . . . . . . . 40
4.2 Environmental Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3 Correctness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.4 Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.5 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Conclusion 50
References 54
Appendices 55
A Prototype blockchain architecture 55
iv
List of Figures
1.1.1 A simple blockchain model . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Energy consumption rate of Bitcoin and Ethereum (13) . . . . . . . . . . 6
1.2.2 Overview of Tendermint’s state machine (25) . . . . . . . . . . . . . . . 8
1.4.1 Chainlink’s VRF model (10) . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.1 Sybil attack example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.2 Routing attack example . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.1 Normal operation of validators and proposer at height h . . . . . . . . . . 23
2.3.2 Eclipsed operation of validators and proposer at height h . . . . . . . . . 23
2.3.3 DDoS operation of validators and proposer at height h round 0 . . . . . . 24
2.3.4 DDoS operation of validators and proposer at height h round 1 . . . . . . 25
2.4.1 Weak randomness possible attack scenario . . . . . . . . . . . . . . . . . 26
3.1.1 Consensus process at a given block height h . . . . . . . . . . . . . . . . 29
3.1.2 Block structure of a VRF-enabled block . . . . . . . . . . . . . . . . . . 34
3.2.1 Random module design . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.2 Example lottery design . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.1.1 Block struct in modified Tendermint Core . . . . . . . . . . . . . . . . . 41
4.1.2 Vrf struct in modified Tendermint Core . . . . . . . . . . . . . . . . . . 41
4.1.3 Vrf struct in modified Tendermint Core . . . . . . . . . . . . . . . . . . 42
4.3.1 Average block formation time under coordinated DDoS attack of Tender-
mint consensus protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3.2 Average block formation time under coordinated DDoS attack of VRF-
enabled consensus protocol . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4.1 Random beacon chain’s scatter plot of node selection over 1000 blocks
for 4 nodes, each with 1 voting power . . . . . . . . . . . . . . . . . . . 45
4.4.2 VRF-enabled consensus protocol’s percentage of node selection over 9852
blocks for 4 nodes, each with 1 voting power . . . . . . . . . . . . . . . 46
v
4.4.3 VRF-enabled consensus protocol’s percentage of node selection over 10224
blocks for 4 nodes, with voting powers equal to 1, 3, 5, 7 respectively . . 46
4.5.1 VRF-enabled consensus protocol’s node0 block formation time measure-
ments over length of 5000 blocks . . . . . . . . . . . . . . . . . . . . . . 48
4.5.2 VRF-enabled consensus protocol’s node1 block formation time measure-
ments over length of 5000 blocks . . . . . . . . . . . . . . . . . . . . . . 49
A.0.1Prototype blockchain overall architecture . . . . . . . . . . . . . . . . . 55
vi
List of Tables
1.3.1 Resistance of secp256k1 and CurveEd25519 to cryptanalytical attacks (16) 11
4.5.1 Average block finalization duration of nodes over 10000 blocks (in ms) . 47
vii
List of Acronyms
DSA
Digital Signature Algorithm.
ECDSA
Elliptic Curve Digital Signature Algorithm.
ECVRF
Elliptic curve verifiable random function.
POS
Proof-of-Stake.
POW
Proof-of-Work.
VRF
Verifiable Random Function.
viii
Introduction
Problem overview
In 2008, a paper called ”Bitcoin: A Peer-to-Peer Electronic Cash” was published by
Satoshi Nakamoto, which proposed a novel type of decentralized system called blockchain
(33). The underlying infrastructure of Bitcoin’s blockchain relies on Proof-of-Work (PoW)
consensus protocol, where block builders (termed miners by the blockchain) compete for
the construction of the next block and the corresponding reward, and PoW has been the
go-to consensus mechanism for alternative chains such as Ethereum.
However, Proof-of-Stake (PoS) consensus protocol and its variants have been steadily
being chosen instead of Proof-of-Work, thanks to their efficiency at generating blocks and
their speed of reaching consensus, allowing for greater versatility for blockchain networks
while still maintaining fairness in reward distribution between block builders (30) (32).
One of the prominent variants of PoS is called Tendermint, which is a Byzantine Fault
Tolerant (BFT)-style PoS mechanism (25). Tendermint is widely adopted in the Cosmos
ecosystem, which in turn is a network of interlocked chains that could communicate with
each other using Cosmos’ Inter Blockchain Communication (IBC) protocol (26) .
Yet, a possible problem of Tendermint lies in its choice of selecting future validator
nodes for block proposals. The consensus protocol opted to use an algorithm to determin-
istically pick the validator node to propose a block for a chosen block height based on the
number of validators and the stake each validator has staked. As a result, malicious actors
have full knowledge about the sequence of block proposers ahead of time, and could pos-
sibly orchestrate distributed attacks (e.g. Distributed Denial of Service (DDoS) or Eclipse
Attack) against nodes right before they are selected to propose the block for the current
height. Repeated attacks on various nodes will severely delay the consensus time and pos-
sibly cripple the entire chain as a result, of which small chains with low node counts are
especially more vulnerable.
On the other hand, although PoS in general and Tendermint in particular could solve
1
some of PoW problems such as energy wastefulness, due to blockchain’s inherent de-
terministic nature, the answer for the outstanding issue of reliably generating random
numbers within the blockchain remains elusive (14), (4). Chainlink’s attempt to solve
this problem, that is utilizing an outside network to supply chains with Verifiable Random
Number (VRF) (10), theoretically could work on any chain, but this leaves smart contracts
and distributed applications heavily relying on a third party service. Moreover, Chainlink
requires specialized smart contracts deployed on the target blockchain, which could render
Chainlink unsuitable for the Cosmos Ecosystem due to its multiple chains nature, since
not every chain in the Cosmos Ecosystem is capable of running smart contracts (i.e. the
Cosmwasm module - Cosmos’ implementation of smart contracts - is not installed for that
chain). Meanwhile, the demand for random numbers on blockchain is quite big. Chain-
link’s VRF Coordinator on Binance Smart Chain - the smart contract that governs the
dispense of random numbers - records as many as 5000 requests per day (2). Thus, Cos-
mos Ecosystem would greatly benefit from having a source of randomness that is reliable
and fast within its vast network - in other words, a random beacon chain - a blockchain
that is capable of distributing verifiable random numbers through smart contracts, or to
other blockchains via the InterBlockchain Communication Protocol.
Goal of esis
In this thesis, we will introduce the concepts of blockchain, Proof-of-Work, Elliptic Curve,
Verifiable Random Function, then evaluate the outstanding problems in Proof-of-Stake
blockchain consensus protocol, in particular Tendermint, and randomness generation in
blockchain in general.
Next, this thesis will research elliptic curve digital signatures and elliptic curve ver-
ifiable random function, as well as selecting the best elliptic curve with highest security
and efficiency, and then implement them into the consensus protocol, evaluate its security,
and use this to build a random beacon blockchain.
Finally, this thesis will demonstrate a prototype blockchain using VRF-enabled cons-
esus protocol, then evaluate different metrics to ensure the correctness, fairness, and per-
formance of said consensus protocol compared to Tendermint.
esis Contributions
The works presented in this thesis bring the following contributions:
1. Improving Tendermint’s consensus protocol, by adding a VRF generation and ver-
2
ification protocol on block creation for choosing the next proposer.
2. Proposing a random beacon chain design based on the random number generated by
the VRF protocol, to be used by smart contracts within the VRF-enabled blockchain
and other smart contracts within the Cosmos Ecosystem via IBC.
3. Improving Chainlink’s VRF by using a more secure elliptic curve.
Main Content and Structure of esis
The remainder of this thesis is structured as follows. In Chapter 2 , we will provide in-
formation about background knowledge related to the proposed model, namely Proof-of-
Stake, Tendermint, Verifiable Random Function, Elliptic Curve. Chapter 3 will provide
information on possilbe attack vectors on blockchain network, including attacks against
the network layer and against the weak randomness of blockchain. The proposed model
design will be presented in Chapter 4, and the implementation and evaluation of the de-
sign will be demonstrated in Chapter 5. Chapter 6 will conclude our research and outline
future works.
3
Chapter 1
Related Works
In this chapter, we will introduce related works to the thesis’ idea. In more detail, Section
1.1 will introduce the concept of blockchain. Section 1.2 will introduce the Proof-of-Stake
consensus, protocol, and Section 1.3 will demonstrate the elliptic curve digital signature,
which will be helpful in Section 1.4, where we learn about Elliptic Curve Verifiable Ran-
dom Function, its algorithm and its application, so that we could discuss further in Chapter
3.
1.1 Blockchain
A blockchain is a decentralized, distributed and public digital ledger that is utilized to
record transactions and share them among many computers in a vast array of comput-
ers. As per its name, blockchain is composed of ”blocks” which are linked together like
a ”chain”, consequently, changing a ”block” means severing the link to all subsequent
blocks down the line, which grows increasingly difficult after each new block is added
onto the blockchain.
Figure 1.1.1: A simple blockchain model
4
Figure 1.1.1 explains a simple model of the blockchain. Block 1 holds the hash of
block 0, and block 2 holds the hash of block 1, and so on. To successfully alter block 1’s
data, an adversary would need to alter the block 2, then block 3, ... until the very end of
the blockchain.
A blockchain is composed of three main components, namely ”block”, ”node”, and
”consensus mechanism”.
Block is the foundation of the blockchain, containing transactions, blockhash, pre-
vious blockhash, timestamp, nonce. The identification of the block are the block
height number and the blockhash, which are used to link blocks together. Altering
one block will cause a cascading effect, requiring the attacker to alter all subsequent
block to avoid being detected by the system, which is increasingly difficult as more
blocks are added onto the system.
Node is the body of decentralization in blockchain ecosystem. Nodes hold infor-
mation about the blockchain, ,ensure that peers are kept updated about the state
of the blockchain in an unanimous manner (.i.e anti-fragmenting), and ensure the
blockchain acquires high availability.
Consensus Mechanism. As nodes need to ensure the unanimity of the blockchain, a
consensus mechanism is required. Historically, the de facto consensus mechanism
is Proof-of-Work, which requires participants - or ”miners” - to compete for the
creation of the next block, but there are now more consensus mechanism emerged
such as Proof-of-Stake, Proof-of-History, Proof-of-Authority which could achieve
higher energy efficience and faster speed.
1.2 Proof-of-Stake Consensus Protocol
1.2.1 Proof-of-Stake
As described in Section 1.1 blockchain is a distributed ledger of records that is shared
between network participant, or so-called ”nodes”, thus it requires nodes to unanimously
agree upon the next set of records - or in formal term, requires a consensus protocol.
There are many different kinds of consensus protocol, in which the most well-known
is Proof-of-Work consensus protocol, coined by Satoshi Nakamoto, and used in their cre-
ation, the Bitcoin blockchain network. But in recent years, Proof-of-Stake consensus pro-
tocol, where block creator is chosen based on the amount of ”stake” they have put into
the consensus mechanism, has been slowly but steadily replacing Proof-of-Work proto-
5
Figure 1.2.1: Energy consumption rate of Bitcoin and Ethereum (13)
col, where nodes compete with each other for being chosen as the block creator through
”work”, as the choice of consensus for building blockchain, due to the formers superior
speed and energy efficiency compared to the latter.
In more details, in a Proof-of-Stake consensus protocol, instead of consuming vast
amount of energy competing to find the next ”hash” of the next block, participants will
elect a leader to act as the block proposer for the next block based on the stakes participants
have staked in the protocol.
Due to this block creation method, Proof-of-Stake enjoys exceptionally high energy
efficiency compared to Proof-of-Work. In particular, Bitcoin energy consumption rate is
14 gigawatts, and Ethereum Proof-of-Work energy consumption rate is 6 gigawatts. This
figure will only become higher and higher over time because block creation difficulty is
ever increasing, in turn the blockchain will requires more hash power to compute the next
block hash.
On the other hand, Proof-of-Stake mechanisms also enjoy superb transaction confir-
mation speed compared to Proof-of-Work, which is measured through Transaction per
Second (TPS). TPS can be computed as follows:
T P S =
B
s
T x
s
× B
cft
(1.1)
where B
s
is the average size of a block, T x
s
is the size of a transaction, and B
cft
is the
average confirmation time of a block. In the case of Bitcoin, its block’s size is 1MB, its
confirmation time is around 10 minutes (or 600 seconds), and average transaction size is
250 bytes, so its TPS is around 6 transactions per second. Proof-of-Stake protocols are not
weighted down by the limitations imposed on Bitcoin network, and on average PoS pro-
6
tocols enjoy vastly superior TPS compared to Bitcoin, for example: Binance Smart Chain
can handle around 150 TPS, Algorand up to 875 TPS, and Ethereum after the changeover
to Proof-of-Stake has a TPS count of 100.000 in theory.
Although there exist many different methods of choosing the next block proposer for
PoS, such as the Follow-the-Satoshi (FTS) method utilized by Tezos(5) or Ouroboros(24),
or a weighted round robin algorithm utilized by Tendermint (31), a proposer selection
method should satisfy two essential properties (6), that are:
1. Determinism, which means at given validator set V, block height h and round r,
the function select(V, h, r) will return the same value, and provides that blockchain
state is replicated.
2. Fairness, which means given a validator set V with total voting power of P, a val-
idator v with a voting power of p should be elected with a frequency of
p
P
over an
arbitrary long time.
1.2.2 Tendermint Consensus Protocol
In 2014, Kwon proposed a novel protocol called Tendermint that implements the Byzan-
tine Fault Tolerant Proof-of-Stake scheme for confirming blocks (25). This protocol at-
tempts to solve the ”nothing at stake” problem of practical byzantine fault tolerance (PBFT)
protocols, by making validators actually need to stake some of their assets to gain the right
to vote for a new block, and they will be penalized if caught performing malicious acts.
The operation flow of Tendermint runs as follows: There are three steps in each round,
namely Propose, Prevote, and Precommit. In Propose step, a deterministic round-robin
algorithm is used to determine the proposer of the next block, and after the new block has
been proposed, the validators will vote for that block in the Prevote step. If more than 2/3
of the voting power voted for a particular block, the consensus will enter Precommit step
and will attempt to commit the validated block to the blockchain, thereby confirming all of
the transactions included in that chain. If the system fails to reach a consensus (.e.g. less
than 2/3 of the voting powers voted for that block, or more than 2/3 of the voting power
broadcasted a nil vote), then a new round will begin until a new block is formed.
Tendermint is proven to be secure under the assumption that the network is partially
synchronized as long as at least 2/3 of the voting power is honest. The protocol enjoys
relatively high transaction throughput and low transaction confirmation time, therefore,
it is currently the backbone of Cosmos Ecosystem, a network of blockchains built from
Cosmos-SDK that are able to communicate with each other through the IBC protocol. Al-
7
Figure 1.2.2: Overview of Tendermint’s state machine (25)
though the protocol is proven to be secure against cryptographic attacks, the deterministic
nature of the round-robin proposer selection algorithm creates a window of opportunity
for attackers to cripple the operation of the blockchain.
1.3 Elliptic Curve Digital Signature
In blockchain systems, Elliptic Curve Digital Signature Algorithm (ECDSA) has been
used predominantly for different cryptographic procedures, such as verifying transac-
tions and creating digital signatures. ECDSA is derived from Digital Signature Algo-
rithm (DSA) using a Koblitz elliptic curve, which is secp256k1 in Ethereum and Bitcoin
blockchains (18). The elliptic curve used for ECDSA, which is also utilized in the Chain-
link’s VRF system, is the elliptic curve secp256k1, which is defined by the Standards for
Efficient Cryptography Group with the following parameters:
P rime number p = 2
256
2
32
2
9
2
8
2
7
2
6
2
4
1
Curve equation y
2
= x
3
+ 7
Generator point G = (55066263022277343669578718895168534
8
326250603453777594175500187360389116729240,
3267051002075881697808308513
0507043184471273380659243275938904335757337482424)
Order n = 115792089237316195423570985008687907852
837564279074904382605163141518161494337
ECDSA comprises of three steps: generating key pair, signature and verification.
1. Key Generation:
(a) Picks a random number i in the range of [0...n-1],
(b) Computes Q = (x
Q
, y
Q
) = iP on the curve secp256k1
(c) The public key is Q, and the private key is i
2. Signing: Given an input message m to be signed, the private key i and hash func-
tion H
(a) Picks a random number k in the range of [1...n-1],
(b) Computes G = (x
G
, y
G
) = kP on the curve secp256k1
(c) Computes r x
G
mod n. If r = 0, recomputes G and r with a new k.
(d) Computes signature s = (r + h a)
(e) Computes s k
1
(H(m) + dr) mod n
(f) Returns the signature pair (r, s)
3. Signature verification: The algorithm to verify a ECDSA signature takes a mes-
sage msg as an input, the pair (r,s) obtained from the signature and the publicKey
corresponding to the signers privateKey. The output is boolean value: valid or
invalid signature. It works as follows:
(a) Computes input e s
1
mod n
(b) Computes u
1
= eH(m) mod n and u
2
er mod n
(c) Computes (x
0
, y
0
) = u
1
P + u
2
Q on the curve secp256k1
(d) Verifies if x
0
r mod n
In 2007, Edwards published a new normal form for elliptic curves (20), then Bernstein
et al. generalized this Edwards form to twisted Edwards curves (9) with the equation:
x
2
+ y
2
= 1 + dx
2
y
2
(1.2)
9
where d k\(0, 1). The sum of two points (x
1
, y
1
) and (x
2
, y
2
) on a twisted Edwards
curve is
(x
1
, y
1
) + (x
2
, y
2
) = (
x
1
y
2
+ y
1
x
2
1 + dx
1
y
2
y
1
x
2
,
y
1
y
2
x
1
x
2
1 dx
1
y
2
y
1
x
2
) (1.3)
where the point (0,1) is the neutral element for addition, and an inversion of (x
1
, y
1
) returns
(x
1
, y
1
).
In 2009, Bernstein proposed Curve25519 (7), which Bernstein also studied and con-
firmed its security and efficiency. This is the basis of Ed25519, a twisted Edwards form
representation of Curve25519, which is used to construct the digital signature Ed25519.
This curve has the following paramenters
P rime number p = 2
255
19
Curve equation x
2
+ y
2
= 1
121665
121666
x
2
y
2
Generator point G = ((151122213495354007725011514095885315114
54012693041857206046113283949847762202 ,
4631683569492647816942839400347516314130799
3866256225615783033603165251855960)
Order n = 2
252
+ 27742317777372353535851937790883648493
Ed25519 also comprises of three steps: generating key pair, signature and verification.
Given input message m and a hash function H that produces a 2b-bits.
1. Key Generation:
(a) Generates a random number k which is in the range of [0...n-1],
(b) Computes H(k) = (h
0
.h
1
, ..., h
2b1
) in binary representation
(c) Computes the integer a = 2
b2
+
b3
i=3
2
i
h
i
(d) Computes the public key A = a G on the curve
2. Signing: The ECDSA signing algorithm takes a message msg as an input, com-
bined it with privateKey and a hash function H. It works as follows:
(a) Compute r = H(h
b
, ..., h
2b1
, m) as an integer modulo n.
(b) Computes a random point R = r G on the elliptic curve.
(c) Computes h = H(R, A, m)
(d) Computes signature s = (r + h a)
(e) Returns the signature pair (R,s)
10
3. Signature verification: The algorithm to verify a Ed25519 signature takes a mes-
sage msg as an input, the pair (R,s) obtained from the signature and the publicKey
corresponding to the signers privateKey. The output is boolean value: valid or
invalid signature. It works as follows:
(a) Computes input: h = H(R, A, m) as an integer
(b) Computes U = 8sB on the curve Ed25519
(c) Computes V = 8R + 8hA on the curve Ed25519
(d) Evaluates if U = V
Meryem et al. analyzed and evaluated Ed25519 against secp256k1, and confirmed
that Ed25519 performs equally or better in at least two different methods of attack on
the cryptographic level, and statistically performs faster than secp256k1 in both key pair
generation and verification (16).
In more details, it is shown that Ed25519 protocol is more resistant to complex-multiplication
field discriminants and Pollard’s rho attack than secp256k1, and is equally resistant to
other types of attacks, as shown in Table
Table 1.3.1: Resistance of secp256k1 and CurveEd25519 to cryptanalytical attacks (16)
Attack Attack condition Resistance of
secp256k1
Resistance of
CurveEd25519
CM field discriminants |D| > 2
100
|D
1
| < 2
2
|D
2
| > 2
254
Pohlig-Hellman n with small fac-
tors
n
1
is prime n
2
is prime
Pollard’s rho small
2
n
1
2
255
is
large
n
2
2
254
is
large
j-variant j = 0 j = 0 j = 0
Anomalous n = p n
1
= p
1
n
2
= p
2
Frey-Rück n | (p
k
1) for
k 30
n
1
(p
1
k
1) n
2
(p
1
k
2)
MOV n = p + 1 n
1
= p
1
+ 1 n
2
= p
2
+ 1
It is also proven that computing on Ed25519 is more efficient than secp256k1, which
is inherently valued in the integration of Ed25519 into the blockchain space, which will
be discussed further in the design section.
11
1.4 Elliptic Curve Veriable Random Functions
1.4.1 Veriable Random Functions
Blockchains generally function in a deterministic and transparent manner, every state of
a blockchain is public and can be verified by any entity through nodes. Thus, generating
unpredictable randomized numbers on blockchain remains a daunting task. A candidate
solution for solving this dilemma is called Verifiable Random Function (VRF), which was
proposed by Micali et al. (29), wherein an entity could generate a pseudo-random number
by utilizing a secret key S
k
, and in turn, can prove the validity and correctness of such
number by revealing the proof π and its public key P
k
.
In more details, a Verifiable Random Function works as follow:
1. The Prover hashes an input alpha using VRF secret key S
k
to obtain and output
beta
beta = V RF _hash(S
k
, alpha) (1.4)
. This algorithm is deterministic, meaning given input alpha and S
k
, the result is
always beta.
2. The Prover also computes a proof π that proves beta is the correct output of V RF _hash:
π = V RF _prove(S
k
, alpha) (1.5)
3. This value π allows anyone to directly computes the output β by using:
beta = V RF _proof_to_hash(π) (1.6)
4. The Verifier then is capable of verifying that beta is the correct VRF hash of input
α by running the verify function with input alpha, proof pi and the Provers public
key P
k
:
is_valid = V RF _verif y(P
K
, alpha, π) (1.7)
which returns (true, beta ) if the output beta is indeed computed in a valid manner.
A secure VRF model should satisfy four distinct properties (19), that are:
1. Pseudorandomness, which means the output y should appear to be statistically ran-
dom, despite being the result of a deterministic function. A well constructed VRF
would satisfies the ”full pseudorandomness” properties, meaning an adversary can-
12
not determines the output beta even when he is able to choose the input alpha, and
cannot reverse engineer output beta
n
after observing n-1 pairs of previous outputs
beta
and proofs pi
.
2. Verifiability, which means the proof π will always be able to return true if the com-
putation is correct.
3. Uniqueness, which means for each P
k
and input x, there cannot be different proofs
π
1
and π
2
for different results y
1
and y
2
. More precisely, the adversary cannot
find a VRF public key P
k
, a VRF input alpha and two proofs π
1
and π
2
such that
V RF _verif y(P
k
, alpha, π
1
) outputs (true, beta
1
) and V RF _verif y(P
k
, alpha, π
2
)
outputs (true, beta
2
).
4. Collision Resistance, which means there cannot exist two distinct inputs x
1
and
x
2
that result in the same output y. More precisely, an adversary cannot find a
VRF public key P
k
, two different inputs al pha
1
and alpha
2
and two proofs π
1
and π
2
such that such that V RF _verif y(P
k
, alpha, π
1
) outputs (true, beta
1
) and
V RF _verif y(P
k
, alpha, π
2
) outputs (true, beta
2
) and beta
1
= beta
2
A particularly efficient construction of VRF is called Elliptic Curve VRF, where the
secret-public key pairs are derived from elliptic curves (17). This version of VRF has been
proven to be fast, secure, and satisfies all of the criteria denoted above. The algorithms
for ECVRF generation is denoted as follows:
1.4.2 ECVRF main functions
For our applications which will be applied in Chapter 4, these algorithms will utilize
the specifications of ECVRF ciphersuite listed as ECVRF-EDWARDS25519-SHA512-
ELL2. Specifications:
1. F: finite field F
2. flen: length of an element in F encoded as a string
3. E: an elliptic curve defined over F
4. ptLen: length of a string resulted from the encode of a point on E
5. G: subgroup of E of large prime order
6. n: prime order of group G
7. nLen: length of n, the smallest integer such that 2
8nLen
> n
8. cLen: length of c, a challenge value defined on VRF
13
9. cofactor: order of E divided by n
10. B: generator of group G
Algorithm 1 ECV RF _P rove
Input: VRF secret key S
k
, input α, generator point B of subgroup G of an elliptic curve
defined over a finite field.
Output: proof π
1: Use S
k
to derive VRF secret scalar x and VRF public key Y = x B
2: Calculate H = ECV RF _encode_to _curve(salt, alpha_string)
3: Calculate h_string = point_to_string(H)
4: Calculate Γ = x H
5: Calculate k = ECV RF _nonce_generation(SK, h_string)
6: Calculate c = ECV RF _challenge_generation(Y, H, Γ, k B, k H)
7: Calculate s = (k + c x) mod n
8: Calculate
π = point_to_string(Γ)||int_to_string(c, cLen)||int_to_string(s, nLen)
9: Return π
Algorithm 2 ECV RF _P roof _to_Hash
Input: VRF proof π, generator point B of subgroup G of an elliptic curve defined over a
finite field.
Output: output string beta
1: Calculate D = ECV RF _decode_proof(π)
2: if D is invalid then
3: Return INVALID
4: end if
5: Decode
, c, s
) =
D
6: Calculate H = ECV RF _encode_to _curve(salt, alpha_string)
7: Calculate u = s B c Y
14
Algorithm 3 ECV RF _V erif y
Input: VRF proof π, Public Key P
k
, input alpha, generator point B of subgroup G of an
elliptic curve defined over a finite field.
Output: Tuple (isV alid, beta)
1: Calculate Y = string_to_point(P
k
)
2: if Y is invalid then
3: Return (false, null)
4: end if
5: if D is invalid then
6: Return (false, null)
7: end if
8: Calculate D = ECV RF _decode_proof(π)
9: Decode , c, s) = D
10: Calculate H = ECV RF _encode_to_curve(salt, alpha_string)
11: Calculate U = s B c Y
12: Calculate V = s H c Γ
13: Calculate c
= ECV RF _challenge_g eneration(Y, H, Γ, U, V )
14: if c
= c then
15: Return (true, ECV RF _proof_to_hash(π))
16: else
17: Return (false, null)
18: end if
1.4.3 ECVRF auxilliary functions
Algorithm 4 ECV RF _Encode_T o_Curve
Input: encode _to_curve_salt, alpha
Output: hashed value H, a point in G
1: string_to_be_hashed = encode_to_curve_salt|| alpha_string
2: Calculate H = encode(string_to_be _hashed)
3: Return
H
Algorithm 5 follows the Edwards-Curve Digital Signature Algorithm mentioned in RFC8032
(23).
15
Algorithm 5 ECV RF _Nonce_Generation following RFC8032
Input: secret key S
k
, string h
s
tring
Output: integer k between 0 and n-1 (n being the order of G)
1: Calculate hashed_sk = Hash(S
k
)
2: Calculate
truncated_hashed_sk = hashed _sk_string[32]...hashed_sk_string[63]
3: Calculate k_string = Hash(truncated_hashed_sk_string||h_string)
4: Calculate k = string_to_int(k_string) mod q
5: Return
k
Algorithm 6 ECV RF _challenge_generation
Input: Elliptic curve points P1, P2, P3, P4, P5
Output: Challenge value x, an integer between 0 and 2
8cLen
1, with cLen the challenge
value of the VRF
1: Assign challenge_generation_domain_separator_front = 0x02
2: Assign suite_string = 0x04 according to ECVRF suite
ECVRF-EDWARDS25519-SHA512-ELL2
3: Assign str = suite_string||challenge_generation_domain_separator_f ront
4: for P
j
in [P
1
, P
2
, P
3
, P
4
, P
5
] do
5: str = str||point_to_string(P
j
)
6: end for
7: Assign challenge_generation_domain_separator_back = 0x00
8: Assign str = str||challenge_generation_domain_separator_back
9: Calculate c_string = Hash ( str)
10: Calculate truncated_c_string = c_string[0]...c_string[cLen 1]
11: Calculate c = string_to_int(truncated_c_string )
12: Return c
Algorithm 7 ECV RF _Decode_P roof
Input: VRF proof π, string length ptLen of a point encoded as string on E
Output: point Γ on E, integer c between 0 and 2
8cLen
1, integer s between 0 and n 1
1: Assign gamma_string = π[0]...π[ptLen 1]
2: Calculate c_string = π[ ptLen]...π[ptLen + cLen 1]
3: Calculate s_string = π[ ptLen + cLen]...π[ptLen + cLen + nLen 1]
4: Calculate Γ = string_to_point(gamma_string)
5: if isV alid(Γ) = f alse then
6: Return INVALID
7: end if
8: Calculate c = string_t
i
nt(c_string)
9: Calculate s = string_to_int(s_string)
10: if s > n then
11: Return INVALID
12: end if
13: Return , c, s)
16
1.4.4 Security Properties
The elliptic curve verifiable random function using the suite CVRF-EDWARDS25519-
SHA512- ELL2 - which means it will generate VRF using the elliptic curve Ed25519
and Elligator 2, elliptic curve points indistinguishable from uniform random string(8) - is
proven to satisfy all of the properties for verifiable random function, namely pseudoran-
domness, verifiability, uniqueness and collision resistance, if the values are generated in
an honest manner, and the verifier obtains specifications such as inputs, curve, provers
public key from publicly verifiable sources, rather than directly from the prover.
1.4.5 Chainlink's application of ECVRF
Chainlink VRF is a random number generation service developed by Chainlink (10).
This service enables users on blockchain to acquire safe and secure random numbers on
blockchains, namely Ethereum and Binance Smart Chain.
The user will first submit a request for a random number and a seed onto the blockchain
through Chainlink’s smart contract. Then, Chainlink will gather the requests, aggregate
them, and deliver them to Chainlink’s oracle, which is an off-chain external network of
nodes, this oracle will generate the random numbers from the seeds provided along with
the requests, verify the results, and submits the results back onto the blockchain through
Chainlink’s coordinator contract, where users can use the results on their own applications.
Recently, Chainlink VRF has introduced its v2 version, which creates a subscription
model for smart contracts, enabling seamless random number requests..
17
Figure 1.4.1: Chainlink’s VRF model (10)
This approach indeed could provide provable-fair and unpredictable random numbers,
but it relies heavily on Chainlink, and in case of service disruption (e.g. Chainlink decides
to temporarily suspend operation), users will be unable to carry on normal operations. Fur-
thermore, this approach limits users on Chainlink’s supported networks, which are mainly
EVM-based blockchains, not to mention the high cost associated with the requesting and
receiving of random numbers from Chainlink’s service.
18
Chapter 2
Possible Aacks on Blockchain System
In this chapter, we will discuss different attack vectors on blockchains, in particular the
possible attacks on network layer of the blockchain, how will it impact the blockchain as
a whole and the consensus algorithm of Proof-of-Stake blockchains in particular.
2.1 Aack Vectors on Blockchain
Broadly speaking, attacks on blockchain can be categorized in four distincts categories
(3).
1. Consensus-layer Attacks: which mainly consists of double-spending attacks and
their variants, such as Finney attacks, race attacks or 51% attacks. Consensus-layer
attacks aim to exploit the confirmation delays in consensus protocols to perform
malicious actions. This should be naturally mitigated with difficulty in block for-
mation and sufficient block confirmation before acknowledging the transactions on
blockchains.
2. Smart Contract Attacks: Smart contracts are the backbone of several prominent
blockchains, such as Binance Smart Chain and Ethereum. Smart Contract Attacks
focus on finding vulnerabilities in smart contracts, such as reentrancy or bugs to ex-
tract funds illegitimately. These attacks are prominent in EVM based blockchains,
and to some capabilities, Rust based smart contracts like CosmWasm. Decentral-
ized autonomous organization (DAO) attacks are one of the most prominent Smart
Contract based attacks, with the infamous The DAO Attack which costed over 70
million USD in damage. Randomization is also an easy target for attacks, since
blockchain is inherently deterministic, and any randomization attempt using only
19
public variables is susceptible to exploitation by malicious actors.
3. Wallet-based Attacks. In reality, there are two kinds of Wallet-based attacks. One
is through wallets such as Metamask, where malicious actors illegitimately obtain
users’ private keys and hold custody of their wallets. Another one is sort of like
smart contract attacks, but targeting multisig wallets - which are basically special
smart contracts. One such attack was the Parity Multisig Wallet attack, where an
attacker exploited ownership insecurity in Parity’s library contract to overwrite him-
self as the new owner, and gaining custody of all Parity multisig wallets.
4. Peer-to-Peer network-based Attacks: Blockchain in reality is a distributed system
run by nodes, and attacks on its network layer is severe to the nature of blockchains
as a whole. This thesis focuses on researching and remedying this kind of attack,
so this will be detailed further below in Section 2.2
2.2 Peer-to-Peer network-based Aacks
In this section, we will introduce four different kind of Peer-to-Peer network-based At-
tacks: Distributed Denial-of-Service, Sybil, Eclipse, and Routing attacks.
2.2.1 Distributed Denial-of-Service
This is the most well-known type of network-layer based attack, where adversaries try
to overload a system by flooding it with redundant requests that could overwhelm the
handling capacity of the system (a denial of service). A Distributed Denial-of-Service
attacks are organized attacks from a huge number of sources, which could be very hard to
mitigate.
2.2.2 Sybil Aack
A sybil attack is where an attacker controls a large number of fake identities to infiltrate
into a network and disrupt its decentralization and permissionless system. To outside
users, a network that has been infiltrated by a sybil attacker does not look any different
from a regurlar network, but in truth the sybil attacker has unfair advantage in the network
by controlling a majority of identities, and could perform malicious actions such as over-
throwing legitimate votes, or even validates fraud blocks. For example, in Figure 2.2.1,
the attacker manifests himself as 6 sybil nodes, achieving a total of 60% majority in the
consensus, practically performing a 51% overriding attack at all time.
On blockchain, Sybil attacks also manifest itself as the form of malicious users faking
20
multiple identities on blockchain to perform actions such as overwriting the majority of
votes on a DAO.
Figure 2.2.1: Sybil attack example
2.2.3 Eclipse Aack
Eclipse attack is a network-based attack that aims to isolate nodes from the entirety of the
decentralized network. This is enacted by overrunning the routing table of the targeted
node before forcing a restart, which will result in the victim node being forced to establish
a connection with the attacker with high probability. From here, the attacker will have full
control over the victim node’s information flow and could perform malicious activities
over the network. Due to the distributed nature of the blockchain, this attack method is
focused on single nodes instead of the entire blockchain network at once.
2.2.4 Routing Aack
Routing attack is where a malicious user tries to manipulate the incoming packets of a
node, by either separating the network into two ”partitions” that could not communicate
with each other, then sending manipulated packages to each side so that they could not
verify the integrity of the packets and would accept it as honest.
For example, in Figure 2.2.2, attackers only need to attack node A and node B to divide
the distributed network into two partitions with no means of cross-communication, thus
can manipulate information sent to each side of the partition
21
Figure 2.2.2: Routing attack example
2.3 Possible Aack Scenarios on Deterministic Proposer Se-
lection Algorithm
As mentioned above, Tendermint’s Proof of Stake consensus protocol selects its next pro-
poser by a deterministic round-robin algorithm, meaning with a given set of validators v,
anyone can calculate and determine the sequence of upcoming block proposer from any
height to any height of their choice. This leaves Tendermint’s consensus protocol vulner-
able to several particular types of network-layer attack vectors, namely the Eclipse Attack
and the Distributed Denial-of-Service Attack, especially with small-scale networks that
have a low number of validators and stable set of validators.
22
2.3.1 Eclipse Aack Scenario on Deterministic Proposer Selection Algo-
rithm
Figure 2.3.1: Normal operation of validators and proposer at height h
Figure 2.3.2: Eclipsed operation of validators and proposer at height h
In a normal configuration (Figure 2.3.1), a proposer would form a block then broadcast
the blocks to other validators on the blockchain via the Gossiping protocol. But, since
the sequence of block proposers is pre-determined, and block time of Tendermint-based
23
blockchains usually is static - 1 second, thus a coordinated adversary could determine
the next proposer on any block height ahead of any arbitrary amount of time, and could
”eclipse” the proposer at the exact moment (Figure 2.3.2).
In a larger scale Proof-of-Stake blockchains with many validators, this would prove
no more than an inconvenience since the vast majority of validators would just timeout
and a new round will begin, but in small scale blockchain, the attacker can forge enough
malicious ”eclipse nodes” that could override the proposers validator threshold, and fal-
sify transactions sending to the proposer, disrupting the network. Furthermore, repeatedly
eclipsing nodes (which is achievable when nodes are configured in close proximity .i.e. on
a local blockchain when nodes are in the same LAN) could severely disrupt the operation
of the blockchain, when validators keep timing out waiting for proposer of blocks.
2.3.2 DDoSAackScenario on Deterministic Proposer Selection Algorithm
Figure 2.3.3: DDoS operation of validators and proposer at height h round 0
24
Figure 2.3.4: DDoS operation of validators and proposer at height h round 1
Similar to Eclipse attack, because the sequence of block proposers is pre-determined, a
coordinated adversary could determine the next proposer on any block height ahead of any
arbitrary amount of time, and could perform a DDoS the proposer at the exact moment
(Figure 2.3.3).
This could even be extended so that the DDoS sequence could match the pattern of
proposer being chosen, with the predetermined time between each round being fixed by
Tendermint, perpetually locking the blockchain in a timing out loop. This attack is difficult
to perform on large scale networks since the nodes are more powerful and their physical lo-
cations are usually far apart enough to cause some coordination difficulty - but not entirely
impossible, if the attackers have enough resources distribute attacking bots near targeted
nodes and pre-programming the sequence of attacks to the attacking stations.
On the other hand, smaller scale blockchains are especially vulnerable to this type of at-
tack due to their limited size and node capabilities, not to mention nodes are usually placed
in close proximity. This attack is easier than performing a network-wide blockchain DDoS
in this scenario, since it costs very little resources, and flooding power is concentrated on
a single node.
25
2.4 Possible Aack Scenarios on Weak Randomization Algo-
rithm
Randomness generation on blockchain is a major concern, since there are a great deal of
services that could utilize randomness, such as games, lottery etc. Attempts were made to
recreate pseudorandom numbers on blockchain utilizing various variables that are readily
available and assumptively unpredictable such as blockhash and block timestamp.
But in truth, variables on blockchain are easy to predict, be manipulated and simu-
lated by the block creators (in certain EVMs based system, miners could possibly even
determine block timestamp themselves within reasonable range).
Figure 2.4.1: Weak randomness possible attack scenario
A possible attack scenario using weak randomization algorithm following the use of
block hash is as follows. The deployer deploys a high-stake lottery contract that uses a
future block hash at height h. When the time comes, the miner of height h could possibly
manipulate the block so that the blockhash is favorable to them, thus destroying the validity
of the lottery.
26
Because of this reason, a strong randomization scheme, which satisfies both secrecy
and verifiable properties is of great importance when considering applications in blockchain
2.5 Precedents
2.5.1 Network-layer Aack
The DDoS attack is, and has been, a major concern in cybersecurity as a whole, since it is
capable of disrupting digital services, which includes blockchain.
In 2022, Solana network suffered from a series of DDoS attacks which is so severe
that the blockchain had to be rolled back, and its token price on the market plummeted as
a result of distrust of investors. The incidents are caused by bots sending duplicated trans-
actions repeatedly to the proposer nodes, overloading their capabilities of acknowledging
and forming of blocks (11).
The aftermath did not stop at blocking users out of the blockchain, it also affected
majority of DeFi users from closing out their position on the blockchain, and as a result,
their position got liquefied since they could not add more collateral to their loans. A roll
back was thus forced, but it resulted in discontent among users towards Solana networks.
Arbitrum network - a layer 2 Ethereum network - also suffered from a particularly
nasty DDoS attack when it launched on September 2022. Although being promoted with
a huge network of validators, bots are still capabale of incapacitating Arbitrum to the point
of total network congestion for 4 hours after launch. Although it does not have the severe
consequence of Solana, Arbitrum’s attack still left users with discontent and discomfort,
affecting the operation of the blockchain as a whole.
On the other hand, there has been no major incident relating to Eclipse attack, but
reports of small scale Eclipse attack are numerous, and this vector is still extensively stud-
ied and analyzed by blockchain experts worldwide, with many warnings against Eclipse
attack by papers and journals (21) (28) (3).
2.5.2 Weak Randomization Aack
There are numerous dApps that utilizes weak randomization on Solidity and EVM based
blockchains which have been exploited, most of them using randomization for generating
NFTs of various rarities.
Most notably, cryptogs, a game of pogs on Ethereum, utilizes blockhash(block.number)
to decide the winner. This can be easily manipulated by the miners. Furthermore, this
27
blockhash can only record up to 255 blocks behind the latest block, further than that and
it will return 0 (22).
This resulted in massive loss for users as attackers could easily manipulate the con-
tracts, putting their pogs ahead of everyone else and withdrawing their pogs before other
users would have the chance to react.
As such, a strong randomization scheme on blockchain is vital in keeping a fair and
secured environment for participants, which will be discussed further below.
2.6 Solutions
The purpose of this thesis is to devise a solution for the above problems, by first utilizing
a strong randomization scheme - meaning, elliptic curve verifiable random function - to
choose the next proposer. This way, adversaries would not be able to determine the up-
coming proposer, and be able to disrupt the blockchain by matching the attack patterns to
blockchain consensus time.
At most, the adversaries could only focus attack on 1 node and fully block that node
outside of the blockchain ecosystem, and if they are lucky, that node could be the proposer
node, delaying the blockchain by 1 round.
Utilizing ECVRF also prevents nodes from exploiting weak randomness to manipu-
late selection algorithm. One possible scenario is one node could manipulate transactions
so that the blockhash always returns a value that will result in the consensus picking that
node again for the next round, if we use a weak randomization function such as the exam-
ples described in Subsection 2.5.2. Using ECVRF ensures that the random value is truly
pseudorandom, which means it cannot be denoted without the private key of the creator,
and public known inputs mean the creator could not manipulate the results according to
their intentions.
Furthermore, ECVRF in consensus protocol enables strong randomness usable in other
functionalities of the blockchain (.i.e. game smart contracts), which could enhance and
extend the usefulness of a blockchain with ECVRF-enabled.
28
Chapter 3
Designing the Consensus Protocol
In this chapter, we will propose a consensus protocol design that implements the Ellip-
tic Curve Verifiable Random Function, and propose a beacon chain model for Cosmos
Ecosystem using a VRF-enabled consensus protocol blockchain.
3.1 Proposal and PreVote Processes
No
Commit
Yes
Figure 3.1.1: Consensus process at a given block height h
Based on the possible attack patterns that stem from the deterministic nature of Tender-
mint’s block proposer selection algorithm mentioned above, we propose some improve-
ments in design toward block proposer selection procedure, which can help mitigate future
29
attacks, especially on small-scale blockchains with few validator nodes. The design is de-
scribed in Figure 3.1.1
In our protocol, the validators also participate in the consensus process by signing
votes for blocks proposed by the proposer, much like Tendermint protocol presented in
Chapter 2. Upon a new round of block formation at block height h, a new proposer for the
next block is chosen. Instead of utilizing a deterministic function to select the proposer,
the proposer is instead chosen by the following function:
proposer = getP roposer(v, t
h1
, r) (3.1)
in which v is the validator set of the previous block (h-1), t
h1
is the random number
generated and included in the previous block, and r is the current round of the height h.
Since the function getP roposer(v , t
h1
, r) is deterministic and only cares about the
values v, t
h1
and r which is publicly known, nodes can verify if they are selected inde-
pendently for that round, thus this step does not require extra communication step between
nodes. Then, the proposer will create a block from the transactions stored in the mempool
and propose this block to the consensus.
In addition to block formation, the proposer also needs to generate a random value t
h
.
This is performed by first creating the alpha input:
m
r
= keccak256(r, h 1, t
h1
) (3.2)
in which h1 is the height of previous confirmed block (0 if it is the first block), and t
h1
is
the random value of the previous confirmed block (0 if it is the first block). Keccak256 is a
secure hash algorithm that is based on sponge construction and demonstrates remarkable
resistance against different attacks (27). After that, the proposer combines m
r
with its
secret key S
k
to generate the proof as follows:
π = ECV RF _prove(S
k
, m
r
) (3.3)
.
Finally, the proposer confirms the final random value by the following formula:
t
h
= ECV RF _proof _to_hash(π) (3.4)
and attaches its public key P
k
and the result t
h
to the proposal, which are broadcasted over
the blockchain via the Gossip protocol to adjacent nodes. When each validator verifies
30
that over two-thirds of the nodes have acknowledged the proposal or a timeout limit has
been reached, the validator enters the prevote step.
In the prevote step, the validator verifies two components. First, it verifies that the pro-
posed block is a valid one, by running an external function isBlockV alid = validate(bl ock
h
).
If isBlockV alid = true, then the validator verifies the random number generated by the
proposer. This is performed by first computing the alpha input using function (3.2) then
the validator runs the following verification function:
(isV RF V alid, t
h
) = ECV RF _verif y(P
k
, π, m
r
) (3.5)
in which t
h
= ECV RF _proof _to_hash(π).
Since each combination of S
k
and m
r
generates a unique proof π, function (3.5) only
returns isVRFValid = true if the proof π (and, in turn, the value t
h
) is calculated in an
honest manner by the proposal. In the last stage, the validator needs to submit its deci-
sion. If both isBlockV alid and isV RF V alid return true and the value t
h
is equal to
t
h
, the validator thus will sign, submit a prevote for the proposed block and broadcast
this prevote to the adjacent validators through Gossip protocol. In any other case (e.g.
isV RF V alid returns false), the validator will sign a nil message and broadcast this pre-
vote to the blockchain.
The rest of the block formation will perform similar to Tendermint’s protocol. In the
beginning of the Precommit step, each validator will make a decision based on how many
prevotes that validator has received for the proposed block. If the prevote count is more
than
2
3
of total prevotes for the proposed block, the validator will sign and broadcast a
precommit for that particular block, and lock onto that block, releasing any prior locks in
the progress. If the node had received more than
2
3
of nil prevotes, it will broadcast a nil
precommit, and just unlock any locked block it has locked on before.
At the end of the Precommit step, each node will count the precommits it received
via the Gossip protocol. If there are more than
2
3
of precommits that are not nil for an
acceptable block, the validator will enter Commit step, otherwise it will ready for the next
round.
At the Commit step, the validator will sign and broadcast for the block it must have
received from the proposer, and then it will wait for other commits from other validators
on the blockchain. When
2
3
of the commits have been received, the validator will set the
CommitT ime to the current time, and enter N ewHeight step, ready to build a new block
to the blockchain. The N ewHeight step is a padding step that lasts for a fixed duration,
its purpose is for slow validators to be able to commit to the previous block.
31
Algorithm 8 PROPOSAL
Input: height h, transactions txs
h
, previous height h 1, validator set v of block h 1
and previous random number t
h1
Output: proposal propose(h, r, block
h
, π
h
, t
h
) or timeout(round
r
).
1: When it is time for NewHeight:
2: Initialize round r with height h, transactions txs
h
, previous height h 1, validator
set v and previous random number t
h1
3: Calculate proposer p
(h,r)
by using getP roposer(v, t
h1
, r)
4: if p
(h,r)
= p then
5: block
h
= createBlock(txs
h
)
6: m
r
= computeInput(r, h 1, t
h1
)
7: π
h
= ECV RF _prove(S
k
, m
r
)
8: t
h
= ECV RF _proof _to_hash(π
h
)
9: Broadcast propose(h, r, block
h
, π
h
, t
h
) to adjacent nodes
10: else if p
(h,r)
= p then
11: Prepare for timeout(round
r
)
12: end if
Algorithm 9 PREVOTE
Input: proposal propose(h, r, block
h
, π
h
, t
h
)
Output: prevote prevote(h
p
, r, id(block
h
))
1: When validator receives propose(h, r, block
h
, π
h
, t
h
):
2: Calculate P
k
by using getP K(p
(h,r)
)
3: Calculate isBlockV alid by using validate(block
h
)
4: Calculate m
r
by using computeInput(r, h 1, t
h1
)
5: Calculate (isV RF V alid, t
h
) by using ECV RF _verify(P
k
, π
h
, m
r
)
6: if isBlockV alid isV RF V alid t
h
= t
h
then
7: Broadcast prevote(h
p
, r, id(block
h
)) to adjacent nodes
id(block) is the unique hash of block
8: else
9: Broadcast prevote(h
p
, r, nil) to adjacent nodes
10: end if
32
Algorithm 10 PRECOMMIT
Input: set of prevotes prevote(h
p
, r, id(block
h
)
Output: precommit precommit(h
p
, r, id(block
h
))
1: When validator receives
2
3
of prevotes.
2: if More than
2
3
of prevotes are nil then
3: Unlocks any locked block.
4: Broadcast precommit(h
p
, r, nil) to adjacent nodes
5: else if More than
2
3
of prevotes are id(block
h
) then
6: Lock on id(block
h
)
7: Broadcast precommit(h
p
, r, id(block
h
) to adjacent nodes
8: else if Less than or exactly
2
3
of prevotes are id(block
h
) Less than or exactly
2
3
of
prevotes are nil then
9: Does not broadcast or lock.
10: end if
At the end of each height, the block committed to the blockchain at height h will have
the random value t
h
and proof π, whose correctness is verified by participating validators,
inscribed onto it, and upon each of the rounds in the consensus process of the next block,
this value will be used to determine the next proposer.
33
Figure 3.1.2: Block structure of a VRF-enabled block
As shown in Figure 3.1.2, the block will contain a VRF segment that includes the VRF
random number t of that block, as well as the public key of the proposer and the proof pi to
prove the correctness of the VRF random number. Everything that is needed to verify the
correctness of t is present in the block, that means everyone would be able to double-check
and verify t at any moment by simply run the function m
r
= keccak256(r, h 1, t
h1
),
then (isV RF V alid, t
h
) = ECV RF _verif y(P
k
, π
h
, m
r
).
This process ensures that a malicious actor cannot predetermine block proposer of
height h for an indefinite amount of time ahead of height h, but can only know the pos-
sible proposer of height h ahead by at most height h 1, preventing him from planning,
34
coordinating and scheduling attacks against upcoming proposers and disrupting the net-
work, ensuring the integrity of the system.
This model does not only work with Tendermint’s protocol, but theoretically could be
applicable to any Proof-of-Stake consensus protocol, since the application of ECVRF does
not depend on Tendermint’s functionalities. Other candidates that could apply ECVRF to
enhance security and privacy includes Tezos and Polkadot.
3.2 Random Module and Beacon Chain
Figure 3.2.1: Random module design
Another improvement that we have devised is the inclusion of the random module,
which retrieves the VRF numbers of the consensus layer and broadcasts it to the appli-
cation layer, allowing users to also utilize this random result. This design is described in
Figure 3.2.1
This module has the IBC capability of Cosmos, and is compatible with the CosmWasm
module (which is the Cosmos’ ecosystem implementation of smart contracts), as a result,
this module is capable of supplying random numbers to smart contracts deployed on the
blockchain ecosystem and enables this blockchain to act as a random beacon chain inside
the Cosmos Ecosystem. This means, that not only users are capable of deploying smart
contracts that use verifiable random numbers on this blockchain, but other chains’ users
can also tap into this blockchain to require a verifiable random number for personal use.
One example of how this module can be used is when a user, for example, Alice, wants
to deploy a lottery system, as shown in Figure 3.2.2. She first writes a smart contract,
35
then specifies which block height will be used for the random number retrieval (which, of
course, should be a future block, otherwise it will defeat the purpose of random number).
Then, at the time of the lottery draw, the smart contract retrieves the random number
t
h
from the predetermined block and calculates the outcome. Anyone could verify the
correctness of t
h
by simply calculating input m
h
and using it along with P
k
and π
h
.
In more detail, in the blockchain, Alice will deploy a smart contract at block i, that
designates the result will be taken from the random value generated from block j. The
smart contract then locks the lottery funds until at least block j. When block j is formed
and added to the blockchain, the smart contract then acquires t
j
from the block, which
could be verified easily by anyone participating in the system, and calculate the winner
based on that.
Figure 3.2.2: Example lottery design
36
One could argue that the validator can possibly manipulate the result of t
j
, but the
ECV RF _verif y(P
k
, π
h
, m
r
) function’s inputs are all determined and publicly known,
which means the outcome t
h
is impossible to manipulate unless the proposer intentionally
forfeits his rights to propose that block and wait for a better chance in the next round,
potentially facing a stake slash and still cannot ensure that the outcome will be favorable
to him. The only possible exploit is collusion between the validators, which would be
detrimental to Proof-of-Stake anyway.
This approach towards random number generation on blockchain is different from
Chainlink’s VRF method in two ways. Firstly, Chainlink VRF relies on a subset of external
actors, and from their consensus, delivers the random number onto the blockchain through
an oracle. Not only does this render users heavily relying on an external factor of the
blockchain and vulnerable to disruption (e.g. when Chainlink decides to go offline), but
it also incurs extra cost for users to pay for Chainlink’s services. On the other hand, the
proposed random beacon chain model’s random number generation is a by-product of the
consensus itself, whose validators have already been rewarded by the consensus algorithm,
thus users can use these random numbers without charge, and as long as all of the nodes
inside the random beacon chain is working properly, users will not have to worry about
service disruption. Secondly, the random beacon chain’s ECVRF construction uses the
Ed25519 elliptic curve instead of Chainlink’s secp256k1, which has been proven to house
numerous advantages, both in security and efficiency as described in Chapter 2.
3.3 Proposed Method Compared To Related Works
Since VRF is a thoroughly researched field, previous applications of VRF into the blockchain
spaces have been presented, such as Algorand or Polkadot, but they are substantially dif-
ferent from the proposed method above.
3.3.1 Algorand
Algorand also aims to solve the problem by incorporating VRFs into its blockchain scheme,
by using VRF during the selection process. The VRF functions similar to a lottery and is
used to choose leaders to propose a block and committee members to vote on a block. This
VRF output, when executed for an account, is used to sample from a binomial distribution
to emulate a call for every algo in a users account. The more algos in an account, the
greater chance the account has of being selected it’s as if every algo in an account par-
ticipates in its own lottery. (15). This method is different from our approach, since instead
of selecting the proposer for the consensus mechanism, Algorand instead selects a set of
37
validators to validate for the proposed block. That means, if you are not selected as a val-
idator, you will not get validation rewards for that particular block, which is detrimental
for small stakers in the network. Furthermore, Algorand is its own standalone blockchain
and does not have the capabilities to interact with other blockchains, which will not be
helpful in the Cosmos ecosystem
3.3.2 Polkadot
Polkadot also has the idea of incorporating VRFs into the blockchain. Instead of deter-
ministically select a block proposer from the function, all of the validators will compute if
their number v is smaller than the network generated number T . That means there could
be many validators selected to produce a block, which requires extra works to select the
next block and does not provide useful work for the network as a whole. And the same
problem occured with Algorand, since Polkadot is a standalone blockchain and does not
have the capabilities to connect to other blockchains, the use of VRF is limited. (12)
There have been ideas raised for Tendermint consensus protocol, but all of them are
merely presented as ”open issues”, and as far as the research goes, there have not been any
research or proposed models to incorporate ECVRF into the Tendermint ecosystem and a
beacon chain model to connect the VRFs to other blockchains within the vicinity.
3.4 Method Advantages and Disadvantages
The proposed method houses several advantages over the normal Tendermint operations:
1. The proposed method has improved Tendermint’s consensus protocol, by adding a
VRF generation and verification protocol on block creation for choosing the next
proposer. This ensures that attackers could only have known the selected proposer
ahead of at most 1 block, ensuring the difficulty of organizing and orchestrating
attacks against the blockchain. The efficiency of attack resistance will be demon-
strated further below.
2. The method allows a way to retrieve the verified VRF to be used for random num-
bers over the blockchain, while using the efficient Ed25519 curve to compute.
Despite this, there are also numerous disadvantages that hinders the incorporation of
the proposed method on the blockchain space:
1. On a larger scale blockchain with hundreds of validators, the observed efficiency of
the novel protocol dwindles, since orchestrating a massive DDoS on such a networks
is nigh impossible either way. Still, this proposed protocol could protect a sole
38
validator from targeted eclipse attacks, preventing that sole node from being totally
isolated.
2. Incorporating the method into existing blockchains would require tremendous ef-
forts, since restarting a blockchain with a new protocol would require all validators
to rewrite the genesis configuration. As such, this protocol should only be applied
for new blockchains.
3. Although not significant, there is still a small computation overhead and network
latency for the computing and verification of verifiable random numbers, which
would be discussed further below.
39
Chapter 4
Implementation and Evaluation
To implement the proposed method as described in section 3, we constructed a prototype
blockchain and will assess it for the qualities of both its selection method correctness and
block formation time, then compare it to Tendermint’s.
4.1 Prototype Blockchain Creation
To create a prototype blockchain and implement the VRF-enabled consensus protocol, we
utilize the Cosmos-SDK, a SDK to build blockchains on Cosmos Ecosystem, and Tender-
mint Core, the original Tendermint consensus protocol. We then proceed to modify the
consensus programming of Tendermint Core to add the VRF implementation. These are all
written in golang. The VRF implementation suite of choice is ECVRF-EDWARDS25519-
SHA512-ELL2, an ECVRF implementation utilizing the curve Ed25519 and points ac-
cording to Elligator 2 standard, as it is the most secure and efficient suite.
In more detail, we modified the struct Block to contain VRF headings, and modified
Validators action to include the proposal action of calculating VRF number, validation of
incoming VRF number, and insert the validation into the struct, as shown in Figure 4.1.1
and Figure 4.1.2
This modified Tendermint Core are then rewired to the Cosmos-SDK, which, in turn,
is rewired into a fork of CosmWasm. This CosmWasm fork, or more precisely, the wasm
module, is also modified to accommodate the VRF number extracted from the consen-
sus protocol, that means (modified) cosmwasm smart contract library could extract these
40
Figure 4.1.1: Block struct in modified Tendermint Core
Figure 4.1.2: Vrf struct in modified Tendermint Core
41
Figure 4.1.3: Vrf struct in modified Tendermint Core
values from the blockchain and utilize it to their purpose, as shown in Figure 4.1.3.
4.2 Environmental Setup
All of the experiments are conducted on four Docker containers deployed on a local net-
work with four distinct IP addresses and ports to avoid network collision. All are run on
the same hardware configuration: a CPU of 2GHz Quad-Core Intel Core i5 and 16GB of
RAM.
The DDoS attacks are performed using Apache Benchmark (1), which simultaneously
generates 60.000 concurrent requests each interval to the targeted node IP address and
port. The number is chosen considering the limits of the testing environment’s bandwidth
and computer resources.
4.3 Correctness
To evaluate the proposed consensus protocol variant against a coordinated DDoS attack,
we ran a simulated DDoS attack against a prototype comprised of 4 nodes and then com-
pared it against Tendermint’s similar setup. Since Tendermint’s proposer selection algo-
rithm is deterministic and in a round-robin fashion, the coordinated attack will know be-
forehand which node is being selected next and is programmed in a predetermined pattern.
When determined a block height to start attacking, the attack algorithm will calculate the
42
0 200 400 600 800 1000
Round
2000
4000
6000
8000
10000
Block Formation Time (ms)
Figure 4.3.1: Average block formation time under coordinated DDoS attack of Tendermint
consensus protocol
designated block height’s proposer node and launch an attack on that node when the time
comes. After that, the attack algorithm will attack subsequent proposers at each timeout
interval according to the round-robin selection algorithm.
Because the proposed model’s selection algorithm uses VRF, the pattern cannot be
determined beforehand, thus we applied the same pattern as Tendermint’s attack to com-
pare the results. At a determined block height, the attack algorithm will pick the proposer
according to Tendermint’s selection algorithm, and then proceed with the attack accord-
ingly.
We then gathered the average block formation time of the nodes and created a scatter
plot. A block formation time of 10000ms means the protocol timed out waiting for the
block proposer to initialize a block.
From the results, we can observe that under coordinated attack, Tendermint’s chosen
proposal nodes mostly cannot perform their function properly, the blockchain constantly
reaches timeout and needs to advance to new rounds, significantly increasing block cre-
ation time. Meanwhile, due to the unpredictability of the new model’s consensus algo-
43
0 200 400 600 800 1000
Round
2000
4000
6000
8000
10000
Block Formation Time (ms)
Figure 4.3.2: Average block formation time under coordinated DDoS attack of VRF-
enabled consensus protocol
rithm, the coordinate attacks cannot always target the new model chain’s proposal nodes,
allowing the network to function properly even with one node losing its functionality.
As long as other nodes can still produce a block proposal, the blockchain can function
properly with one node down. There are still occasions when the proposal node is the
targeted node, and in such cases, the network will timeout and need to move to a new
round, but compared to Tendermint’s consensus protocol, the successful consensus rate is
significantly higher.
In more detail, out of 1000 rounds, 92.5% of Tendermint’s consensus protocol rounds
reached timeout without being able to finalize blocks when under coordinated attacks,
meanwhile the figure is only 52.8% with the proposed variant, as seen by the distributions
observed in Figure 4.3.1 and 4.3.2 - in which the red dots denote timed out rounds and the
blue dots denote the average block formation time of completed block.
4.4 Fairness
As discussed in Chapter 2, Proof-of-Stake selection process should satisfy two essential
qualities, Determinism and Fairness.
44
0 200 400 600 800 1000
Height
0
1
2
3
Node
Figure 4.4.1: Random beacon chain’s scatter plot of node selection over 1000 blocks for
4 nodes, each with 1 voting power
1. Determinism: The choice of implementing ECVRF using the elliptic curve already
ensures the determinism of the consensus, since function (3.2) and sequentially
function (3.3) are both deterministic. As long as the state of blockchain is repli-
cated from the genesis block, the sequence of random values t will be replicated
one by one.
2. Fairness: One of the key values of ECVRF lies in its full pseudorandomness, which
was proven by S. Goldberg et al (19). In short, ECVRF ensures that someone with-
out knowledge of secret key S
k
will not be able to distinguish the outcome t
h
from a
random value. Furthermore, the proposer cannot choose the input m
r
, but needs to
conspicuously perform a predetermined function (3.2) to generate the VRF number.
To further clarify, we first performed a pseudorandom distribution test, then we per-
formed a test on the prototype with 4 nodes and analyzed the results of block proposer
selection over a range of approximately 10,000 blocks multiple times to verify the fair-
ness of the consensus.
45
1 2 3 4 5 6 7
1
2
3
4
5
6
7
Node0
25.2%
(2481)
Node1
24.3%
(2392)
Node2
25.1%
(2469)
Node3
25.3%
(2486)
Figure 4.4.2: VRF-enabled consensus protocol’s percentage of node selection over 9852
blocks for 4 nodes, each with 1 voting power
Figure 4.4.3: VRF-enabled consensus protocol’s percentage of node selection over 10224
blocks for 4 nodes, with voting powers equal to 1, 3, 5, 7 respectively
46
Table 4.5.1: Average block finalization duration of nodes over 10000 blocks (in ms)
Node VRF-powered Chain Tendermint
Node 0 958.333121780022 945.4388912947659
Node 1 958.1333696459159 946.0899973030309
Node 2 958.2167081699193 946.0843910854002
Node 3 958.4829165905359 946.0987231019282
From the scatter plot depicted in Figure 4.4.1, it is shown that the algorithm will dis-
tribute the selection throughout 4 nodes in a fairly even manner, without many gaps or
clusters. Over a longer period of time, this distribution will gradually reach a discrete
uniform distribution.
This is backed by the data shown in Figure 4.4.2 and 4.4.3. With a testing sample of
approximately 10,000 blocks, the chance of a block being selected as the proposer is an
approximation of the function:
c
i
=
p
i
P
=
p
i
n1
i=0
p
i
(4.1)
in which p
i
is the voting power of node i. In an arbitrarily long sequence of blocks, this ap-
proximation should gradually reach the ratio of the round-robin algorithm that Tendermint
has developed.
For the above experiments, we see that this random beacon chain model’s consensus
algorithm satisfies both determinism and fairness for the proposer selection process, and
adds an extra layer of protection against potential attack vectors.
4.5 Performance
To evaluate the performance of this random beacon chain model’s consensus algorithm
and the impact of VRF calculation, we will conduct several tests over the length of ap-
proximately 10000 blocks to measure the block finalization time of each node, from the
initialization of block height h (i.e. upon NewHeight trigger) to the initialization of block
height h + 1. This is evaluated on a constant input stream of roughly 3 transactions per
second.
Since validator nodes can perform the selection function independently, there exists
no extra communication delay between nodes, and there is only a slight overhead of 12ms
47
0 1000 2000 3000 4000 5000
Round
600
700
800
900
1000
Block Formation Time (ms)
Figure 4.5.1: VRF-enabled consensus protocol’s node0 block formation time measure-
ments over length of 5000 blocks
for each node due to the calculation and verification of VRF, as shown in Table 4.5.1.
We also plotted a graph of individual duration measurements of block formation time
on two nodes over 5000 blocks. From Figure 4.5.1 and 4.5.2, we can see that the block
finalization duration of node0 and node1 stay mostly stable throughout a sequence of 5000
blocks and a constant input rate of 3 transactions per second, with some occasional anoma-
lies, but there recorded no timeout and no severely delayed block finalization time.
From these results, we concluded that the addition of ECVRF into the consensus pro-
cedure does not cause critical degradation or severe delay in block formation, and the
performance of the random beacon chain’s consensus algorithm is comparable to that of
Tendermint’s while keeping the selection procedure safer and more secure.
48
0 1000 2000 3000 4000 5000
Round
600
700
800
900
1000
Block Formation Time (ms)
Figure 4.5.2: VRF-enabled consensus protocol’s node1 block formation time measure-
ments over length of 5000 blocks
49
Conclusion
This thesis has demonstrated the outline of the problems with the current Proof-of-Stake
consensus protocol, in particular Tendermint consensus protocl, and proposed a new con-
sensus design powered by a provably fair Elliptic Curve Verifiable Random Function,
which, as demonstrated through experiments, possesses the capability to mitigate network-
based attack vectors while retaining the determinism, fairness, and performance of the
Tendermint consensus protocol.
Furthermore, the preinstalled random module built underlying the Cosmwasm module
allows this random beacon chain to act as a random beacon chain, both to serve provably
fair random numbers to smart contracts deployed within the network and to serve random
numbers for adjacent blockchains throughout the Cosmos Ecosystem through the IBC
protocol.
Future works in this area involve developing on-demand number generation requests,
i.e. allowing validators to process random number requests from smart contracts much like
Chainlink’s model, and aiming to further improve the performance of this novel random
beacon chain model.
50
Bibliography
[1] Apache http server benchmarking tool, 2023. Last accessed: 2023-09-12. URL:
https://httpd.apache.org/docs/2.4/programs/ab.html.
[2] Chainlinkvrfcoordinator smart contract, 2023. Last ac-
cessed: 2023-09-12. URL: https://bscscan.com/address/
0xc587d9053cd1118f25F645F9E08BB98c9712A4EE.
[3] Shubhani Aggarwal and Neeraj Kumar. Chapter twenty - attacks on blockchain
- working model. In Shubhani Aggarwal, Neeraj Kumar, and Pethuru Raj, ed-
itors, The Blockchain Technology for Secure and Smart Applications across In-
dustry Verticals, volume 121 of Advances in Computers, pages 399–410. Else-
vier, 2021. URL: https://www.sciencedirect.com/science/article/pii/
S0065245820300759, doi:10.1016/bs.adcom.2020.08.020.
[4] Peter Alleman. Randomness and games on ethereum, 2021. URL: https://
crypto.unibe.ch/archive/theses/2021.msc.peter.allemann.pdf.
[5] Victor Allombert, Mathias Bourgoin, and Julien Tesson. Introduction to the tezos
blockchain. pages 1–10, 07 2019. doi:10.1109/HPCS48598.2019.9188227.
[6] Antonina Begicheva and A Kofman. Fair proof of stake. 05 2018. doi:10.13140/
RG.2.2.11204.37765.
[7] Daniel J. Bernstein. Curve25519: New diffie-hellman speed records. In Moti Yung,
Yevgeniy Dodis, Aggelos Kiayias, and Tal Malkin, editors, Public Key Cryptography
- PKC 2006, pages 207–228, Berlin, Heidelberg, 2006. Springer Berlin Heidelberg.
[8] Daniel J Bernstein, Mike Hamburg, Anna Krasnova, and Tanja Lange. Elligator:
elliptic-curve points indistinguishable from uniform random strings. In Proceed-
ings of the 2013 ACM SIGSAC conference on Computer & communications security,
pages 967–980, 2013.
51
[9] Daniel J. Bernstein and Tanja Lange. Faster addition and doubling on elliptic curves.
In Kaoru Kurosawa, editor, Advances in Cryptology ASIACRYPT 2007, pages 29–
50, Berlin, Heidelberg, 2007. Springer Berlin Heidelberg.
[10] Lorenz et al. Breidenbach. Chainlink 2.0: Next steps in the evolution of de-
centralized oracle network, 2021. URL: https://naorib.ir/white-paper/
chinlink-whitepaper.pdf.
[11] Quarmby Brian. Solana hit with another network incident causing de-
graded performance, 2022. URL: https://cointelegraph.com/news/
solana-hit-with-another-network-incident-causing-degraded-performance.
[12] Jeff Burdges, Alfonso Cevallos, Peter Czaban, Rob Habermeier, Syed Hosseini,
Fabio Lama, Handan Kilinc Alper, Ximin Luo, Fatemeh Shirazi, Alistair Stew-
art, and Gavin Wood. Overview of polkadot and its design considerations, 2020.
arXiv:arXiv:2005.13456.
[13] Beekhuizen Carl. Ethereum’s energy usage will soon decrease by 99.95
percent, 2021. URL: https://blog.ethereum.org/2021/05/18/
country-power-no-more.
[14] Krishnendu Chatterjee, Amir Kafshdar Goharshady, and Arash Pourdamghani.
Probabilistic smart contracts: Secure randomness on the blockchain. In 2019 IEEE
International Conference on Blockchain and Cryptocurrency (ICBC), pages 403–
412, 2019. doi:10.1109/BLOC.2019.8751326.
[15] Jing Chen and Silvio Micali. Algorand: A secure and efficient distributed ledger.
Theoretical Computer Science, 777:155–183, 2019. In memory of Maurice Ni-
vat, a founding father of Theoretical Computer Science - Part I. URL: https://
www.sciencedirect.com/science/article/pii/S030439751930091X, doi:
10.1016/j.tcs.2019.02.001.
[16] Meryem Cherkaoui Semmouni, Nitaj Abderrahmane, and Mostafa Belka-
smi. Bitcoin security with a twisted edwards curve. Technical report,
2019. URL: https://normandie-univ.hal.science/hal-02320909v1/file/
EdwardsBitcoinFinal-V3.pdf.
[17] Yevgeniy Dodis and Aleksandr Yampolskiy. A verifiable random function with short
proofs and keys. In Serge Vaudenay, editor, Public Key Cryptography - PKC 2005,
pages 416–431, Berlin, Heidelberg, 2005. Springer Berlin Heidelberg.
52
[18] Johnson Don, Menezes Alfred, and Vanstone Scott. The elliptic curve digital signa-
ture algorithm (ecdsa). In International Journal of Information Security. Springer,
2001.
[19] S. Golberg and L. Reyzin. Verifiable random function. Technical report, 2023. URL:
https://www.rfc-editor.org/rfc/rfc9381.pdf.
[20] M. Edwards Harold. A normal form for elliptic curves. In Bulletin of the American
Mathematical Society 44, pages 393–422. AMS, 2007.
[21] Ethan Heilman, Alison Kendler, Aviv Zohar, and Sharon Goldberg. Eclipse attacks
on Bitcoin’s Peer-to-Peer network. In 24th USENIX Security Symposium (USENIX
Security 15), pages 129–144, Washington, D.C., August 2015. USENIX Asso-
ciation. URL: https://www.usenix.org/conference/usenixsecurity15/
technical-sessions/presentation/heilman.
[22] Song Jonghyuk. Attack on pseudo-random number generator(prng)
used in cryptogs, an ethereum (cve-2018–14715), 2018. Last ac-
cessed: 1-10-2023. URL: https://medium.com/coinmonks/
attack-on-pseudo-random-number-generator-prng-used-in-cryptogs-an-ethereum-cve-2018-14715-f63a51ac2eb9.
[23] Simon Josefsson and Ilari Liusvaara. Edwards-Curve Digital Signature Algorithm
(EdDSA). RFC 8032, January 2017. URL: https://www.rfc-editor.org/
info/rfc8032, doi:10.17487/RFC8032.
[24] Aggelos Kiayias, Alexander Russell, Bernardo David, and Roman Oliynykov.
Ouroboros: A provably secure proof-of-stake blockchain protocol. In Jonathan Katz
and Hovav Shacham, editors, Advances in Cryptology CRYPTO 2017, pages 357–
388, Cham, 2017. Springer International Publishing.
[25] Jae Kwon. Tendermint: Consensus without mining. Technical report, 2014. URL:
https://tendermint.com/static/docs/tendermint.pdf.
[26] Jae Kwon and Ethan Buchman. Cosmos whitepaper, 2019. URL:
https://wikibitimg.fx994.com/attach/2020/12/16623142020/
WBE16623142020_55300.pdf.
[27] Jiasong Liu. Digital signature and hash algorithms used in Bitcoin and Ethereum.
In Shuhong Ba and Fan Zhou, editors, Third International Conference on Ma-
chine Learning and Computer Application (ICMLCA 2022), volume 12636, page
126365H. International Society for Optics and Photonics, SPIE, 2023. doi:10.
1117/12.2675431.
53
[28] Yuval Marcus, Ethan Heilman, and Sharon Goldberg. Low-resource eclipse attacks
on ethereum’s peer-to-peer network. Cryptology ePrint Archive, Paper 2018/236,
2018. https://eprint.iacr.org/2018/236. URL: https://eprint.iacr.
org/2018/236.
[29] S. Micali, M. Rabin, and S. Vadhan. Verifiable random functions. In 40th Annual
Symposium on Foundations of Computer Science (Cat. No.99CB37039), pages 120–
130, 1999. doi:10.1109/SFFCS.1999.814584.
[30] P.R. Nair and D.R. Dorai. Evaluation of performance and security of proof of work
and proof of stake using blockchai. In Third International Conference on Intelligent
Communication Technologies and Virtual Mobile Networks, pages 279–283. IEEE,
2019.
[31] Cong T. Nguyen, Dinh Thai Hoang, Diep N. Nguyen, Dusit Niyato, Huynh Tuong
Nguyen, and Eryk Dutkiewicz. Proof-of-stake consensus mechanisms for future
blockchain networks: Fundamentals, applications and opportunities. IEEE Access,
7:85727–85745, 2019. doi:10.1109/ACCESS.2019.2925010.
[32] Moritz Platt, Johannes Sedlmeir, Daniel Platt, Jiahua Xu, Paolo Tasca, Nikhil
Vadgama, and Juan Ignacio Ibañez. The energy footprint of blockchain consensus
mechanisms beyond proof-of-work. In 2021 IEEE 21st International Conference on
Software Quality, Reliability and Security Companion (QRS-C), pages 1135–1144,
2021. doi:10.1109/QRS-C55045.2021.00168.
[33] Nakamoto Satoshi. Bitcoin: A peer-to-peer electronic cash system, 2008. URL:
https://bitcoin.org/bitcoin.pdf.
54
Appendix A
Prototype blockchain architecture
In this thesis, Cosmos-SDK, Tendermint Core and CosmWasm is used and modified heav-
ily. This appendix will display the overall architecture of the components that made up
the overall structure of the prototype blockchain, and where the modifications took place.
Figure A.0.1: Prototype blockchain overall architecture
As shown in Figure A.0.1, the prototype blockchain core is the modified Tendermint
Core, which houses the VRF algorithm. The ECVRF generation and verification changes
happen here. It connects to Cosmos-SDK via Application BlockChain Interface (ABCI),
and sends information about the blocks to the application layers. The smart contracts
that are deployed will connect to the cosmwasm module, and extracts the random number
from the environment housed in the core of the module, a modified cosmwasmvm. Since
55
cosmwasm is fully capable of InterBlockchain Communication, this module will enable
other smart contracts from other blockchains to interact and extracts the random number
housed in the prototype blockchain to gain their own use.
56